Packet data networks are increasingly used for the exchange of realtime audio, video and data communications. Various protocols, including the H.323 protocol, require the establishment of a call signaling channel that is separate from the bearer channel. The call signaling channel is used to exchange signaling messages, such as call setup, tear down, address translation and messages related to billing.
With reference to FIG. 1 in connection with realtime communications over packet data networks, or IP telephony, a signaling channel is usually established over the IP network 100 between a media gateway 104 and/or communication device 108 on the one hand and a primary communication server 112, providing call controller functionality for basic call service and for various call feature support, on the other. Failure of the network 100 (or a link in the network) or the primary server 112 such that the call signaling channel is lost can lead to a service outage at the media gateway 104 or communication device 108. In order to prevent a loss of service under such circumstances, an alternate or secondary communication server 116 is typically provided. However, when a media gateway 104 or communication device 108 migrates to the secondary communication server 116, the existing calls (i.e., the bearer channels) may get torn down. Even if they are not torn down, it is likely that no call features will be available to the media gateway 104 or communication device 108, since the secondary communication server 116 has no knowledge of the call state information associated with the calls. In particular, preservation of call features in addition to bearer connections requires that the secondary communication server 116 be supplied with call state information.
To provide call state information to a secondary communication server 116, such information can be stored in a database that can be accessed by all primary and secondary servers. However, establishing a common, redundant database can be expensive. In addition, such databases can create a data bottleneck, especially when a large number of servers are accessing the database. Furthermore, such a solution is not very robust, as network failures can prevent call controllers from accessing the common database.
Another approach to providing call state information to secondary communication servers 116 dynamically updates available secondary communication servers 116 with call state information. That is, as call state information is generated or updated, that information is provided to the secondary communication server 116 that would be contacted by the client if the primary communication server 112 were lost. However, this approach adds overhead and complexity, particularly as the number of communication servers available on a system increases. In addition, the secondary communication servers 116 must be updated with call state information regarding all of the calls on the primary communication server 112. This can result in network congestion. In addition, the solution is not very robust, as network failures can prevent servers from communicating with one another.
In yet another approach, the components of the calls are not merged; in other words, they are reconstructed as separate calls. The separate calls, however, would not behave the same with respect to some features as the original or a merged call. For example, it is possible that a component separately reconstructed as a call has no disconnect supervision.
In yet another approach, the secondary communication server 116 attempts to reconstruct stable calls (calls with established talk paths) on the gateway 104 by querying the gateway 104 for call state information. The call state information was saved by the primary communication server 112 when it originally created the call on the gateway 104. However, where a call spans multiple gateways (or includes one or more inter-gateway connections (which commonly is an IP-bearer connection between two gateways on a common or shared primary communication server)), such as a call between communication devices 108a and b (which spans gateways 104a and b), a naive call reconstruction algorithm would, as the call components migrate, reconstruct the part of the call handled by each gateway as a separate or new call, which, as noted above, can cause some features to be lost to the communicants.